The design and creation of services in the Home Network Environment has encountered many hurdles, the biggest is the need for every device on the network to be able to communicate with the different servers in the Home Network (HN) and in the outside External (say, Internet) Network. Although many protocols standardized many various services, the current technology is still oriented to specific services and does not provide the flexibility to create new services without going through the whole process of standardization of the new services from end to end with all participants in the service actualization process.
Presently existing home or residential gateways between a home network and an external network (such as Internet, Ethernet, etc.) are capable of supporting communication between the two networks and enable providing some basic services for users of the home network (for various network devices). However, it should be noted that the mentioned capability is ensured by using (or providing) quite complex hardware and software means both at the side of home network devices, and at the side of servers of the external network (such as IP servers). Any new and/or technologically advanced service which is desired for the home network devices becomes problematic (beginning from just installing and connecting a new home network device, up to any novel service requiring participation of a group of network devices of the interconnected networks). The problem stems from the need of intervention into the existing software architecture of the home network devices, of the home gateway and/or of the external networks services, and thus from the need of seeking and producing new program “patches” for performing each of the newly required services.
FIG. 1 (prior art) illustrates a well known and widely used architecture of a Home (or Residential) gateway RG (110), serving a home network 100 where each of the home network devices HND1-HNDN (101-104) is intrinsically capable of communicating with an external network 120 via the Home gateway 110. In this example, the external 120 network is IP network which may further be referred to as IN. Network devices of the IP network 120 are represented by a number of servers IS1-ISN (121-124). FIG. 1 depicts the standard methodology for creation of services in the home network 100. Home Network Devices HND 101-HND 104 must all be IP capable (with either integrated IP capabilities or an additional adaptor device). HNDs may have Ethernet or IP connectivity among them over the Home Network (100). When a need arises to reach an external server, an HND creates service related sessions via the Residential Gateway (110). The RG (110) provides various connectivity services to the Home Network: Bridge Services (111), Router Services (112) which may include Network Address Translation NAT and Firewall, Proxy Services (113) and Application Level Gateway Services (ALG 114). Using any of these connectivity services, the Home Network Device (say, 101) sends messages over the Internet Network (120) and reaches the necessary servers that take care of the message.
A schematic example of a simple service can be seen in FIG. 2 (prior art), illustrating the message interplay related to a Content Retrieval service (the details are provided to demonstrate the complexity of the service performed by the prior art gateway). First phase (211) demands IP initialization of the Home Network (Residential) Gateway RG (202) from a Dynamic Host Control Protocol DHCP Server (203). Then Home Network Devices (generally marked 201) get their Local IP addresses from the RG (202). Second Phase (212) includes Configuration of the HND (201) by an Auto-Configuration Server ACS (204). Third Phase (213) is the phase where the HND 201 can access the content, which is provided by HTTP Server (205). The service creation and service actualization for other services is even more complicated then the content retrieval service. In other services different protocols can be involved (e.g. SIP or H.232), other servers can be used (Call Server, Video Servers).
In case the desired service demands a combination of services (e.g., a combination of voice, data, and video), specific applications—say, similar to “Net-Meeting” must be built on a PC-like device for that specific service, without having a possibility to use them for other services.
In parallel to the service actualization, the end-to end network must be configured to support the service. In the solutions that exist today, these tasks are split between the service provider (from server to the residential or home Gateway) and the user (from the Gateway to the HND). Harmonization of these tasks is still under debate; either RG will take care of assuring end-to-end requirements or external controller will do it as part of IMS (IP Multimedia Subsystem) concept.
Addresses of Network layer commands arriving to the Gateway either from the side of Home Network or from the side of External Network have to be translated, in any direction. The function of coordination the Home Network Devices addresses with External Network (IP) addresses is usually performed with the aid of modules like NAT (Network Address Translation), ALG 114 (Application Level Gateway) or Proxy. NAT is indicated as 206 in FIG. 2, ALG and Proxy are respectively marked as 114 and 113 in FIG. 1.
In presently known solutions, many of the HN attributes are discovered, configured and directly controlled by the IN or Service providers (e.g. Technical Report DSL Forum TR-094, (August 2004) www.dslforum.org/techwork/tr/TR-094.pdf.
Having described today's solution for service creation and delivery, it is evident that any attempt to introduce new services demands understanding of Home Network technologies, Provider Network architectures and protocols, as well as the capability to integrate all technologies into a valid end-to end service delivery platform.
U.S. Pat. Nos. 6,930,598 B2 “Home Gateway Server Appliance” and U.S. Pat. No. 6,317,884 B1 “Video, Data and Telephony Gateway” describe various solutions that still do not solve the problem of cumbersome and complex coordination of services and protocols of different inter-communicating networks, as well as the problem of intrinsic capabilities of different network devices belonging to these different networks.
A relatively novel technology called PARLAY (http://www.parlay.org/en/specifications/) has been developed for supporting telecommunication services between a number of standard network applications and a telecommunication network. The Parlay Group aims to link Information Technology (IT) applications with the capabilities of the telecommunications world by specifying and promoting application programming interfaces (APIs) that are easy to use, rich in functionality, and based on open standards. Parlay integrates telecom network switches with IT applications via a secure, measured, and billable interface. Parlay presents the notion of an API that allows applications to interface the Telecommunication Network (for example, a central office of a PSTN network) with the aim to allow multiple network services to be then offered to telephony users.
U.S. Pat. No. 6,690,782 B2 describes a way of implementing the Parlay concept between an application layer, a service layer and a protocol layer of a telecommunications network. Neither Parlay, nor the U.S. Pat. No. 6,690,782 B2 has reference to a home network, specific home network devices, nor specific home network services.